Presently, there exists a large body of legacy code written in C or C++. Often, it is desirable to extend the functionality of this code by writing new applications, which become new modules in C or C++. Such applications include online hot patching and a Just-In-Time compiler. Writing these new applications depends on accessing symbols contained in the legacy code, but often the needed symbols are unavailable. If so, the new applications cannot be dynamically linked in, rendering them inoperable.
Static linkers do not encounter this problem because in the intermediate steps between compiling a program and generating a resulting binary, all symbol information is included in an object file such that the static linker can resolve all of the symbols.
Dynamic linkers do not encounter this problem if all of the symbols are exported and no private symbols are used in the modules. Private symbols occur if a symbol in a C program is annotated with the ‘static’ keyword, which forces the symbol to be private in the current C module. Thus, private symbols cannot be resolved with dlsym( ) call at runtime and a new module cannot be linked in with the current running binary if the new module makes references to private symbols in the original binary.
Attempts have been made to solve the private symbol problem, but none has proven satisfactory.
One attempt is to remove all ‘static’ references, but doing so is not practical with large code bases, which may frequently use the ‘static’ keyword.
Another attempt is to manually inspect and resolve all ‘static’ symbols that are used by the new module and explicitly export those symbols. The Linux Kernel has an explicit EXPORT_SYMBOL macro, which does this on a per module basis. However, manual inspection is very error prone. Whenever a new module requires a new reference to an existing private symbol, the author must also modify the original program.
Yet another attempt includes writing a C parser that parses the original C program to resolve and export private symbols. However, writing a C parser is very difficult to get right due to the C macro system. In addition, the author may not have access to all of the modules in the original C program, some of which define the symbols needed by the author. In this case, the author must manually write a wrapper function to export the private symbol.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.